fix(app-shell): drop the undeclared chart.config forward on the object-chart node (objectui#7891) - #7948

Fixes #7891

Clause-②: no

ObjectView's dedicated chart-view route put config: chartConfig.config on the
object-chart schema it builds, on both branches — :2118 (ADR-0021 dataset) and :2152
(legacy). This drops both rungs, and the two as any casts that turned out to be inert.

The card's premise was inverted before this PR, and the inversion is the fix

The card was filed as "ListView is missing a config rung that the dedicated chart route
has". The measurement that preceded this work reversed it: ListView is not missing a
channel — app-shell had an extra one no author is allowed to feed.

@objectstack/spec@17.2.0's ListChartConfigSchema is a strictObject whose declared
keys are exactly chartType / dataset / dimensions / values, and objectui binds it
BY REFERENCE (chart is absent from LIST_VIEW_LOCAL_OVERRIDES,
packages/types/src/zod/objectql.zod.ts:312), so ListViewSchema.chart IS the spec's
strict schema. A view body carrying the key is refused by name.

So this was never one authored declaration rendering two ways. It was an asymmetry between
two UNDECLARED channels — and ObjectChartSchema does not declare config either, so the
key landed on a node that had no name for it.

The blocking measurement this dispatch required: can chart.config reach STORED data?

No — the write door refuses it, and no producer exists. Four readings:

1. The write door parses every save through the same schema.
   saveMetaItem (objectstack packages/metadata-protocol/src/protocol.ts:15149) calls
   resolveOverlaySchema(type) to getMetadataTypeSchema('view')
   (objectstack packages/spec/src/kernel/metadata-type-schemas.ts:110), safeParses, and
   answers 422 INVALID_METADATA on failure. There is no early return between the mode
   fold and that gate, and the gate reads neither mode nor force — so it runs on
   mode: 'draft' (what app-shell's persistRuntimeMetadata sends) exactly as on publish.
   Run against the published spec build this repo resolves, from inside its real dependency
   graph:

   getMetadataTypeSchema present = function
   view schema resolved          = true
   CONTROL (no config)  success = true
   WITH chart.config    success = false
     unrecognized_keys keys=["config"] path=["config","chart"]
     message=Unrecognized key(s) on this list chart configuration: `config`. Until #4001
     closed these shapes an unknown key was dropped silently — the view still rendered,
     without whatever the key was meant to configure.
   

2. The authoring UIs cannot mint it. ViewConfigPanel hosts the studio's
   ViewVariantInspector, which renders the per-view-type fields straight from
   @objectstack/spec; CreateViewDialog's chart field list is chartType /
   xAxisField / yAxisFields. view-config-adapter round-trips unknown keys, so it would
   PRESERVE a stored one — but it originates nothing, and a save carrying one would now hit
   the 422 above.

3. No producer exists in this repo. config: chartConfig.config at :2118 / :2152
   were the only two occurrences of the pattern anywhere in the tree.

4. No stored fixture carries it. A structural scan (any object at key chart owning a
   config key, at any depth) over every tracked JSON file: 0 hits in objectui (544
   files parsed of 6485 tracked) and 0 in objectstack (444 parsed).

Legacy rows could in principle predate the #4001 tightening — which is exactly the risk the
next section bounds — but nothing measurable here produces or holds one.

Degrade, not break

packages/plugin-charts/src/ChartRenderer.tsx:151-160 auto-generates a container config
from series plus a positional palette when config is absent, so any non-conforming row
that somehow existed still renders — it falls back to series-derived labels and default
chart colours. The spec's own refusal message says the same thing about the class:

Until #4001 closed these shapes an unknown key was dropped silently — the view still
rendered, without whatever the key was meant to configure.

Why nothing ever caught this, and why the casts went too

Not the as any. One layer further out: ObjectChart is published as (props: any)
(packages/plugin-charts/src/ObjectChart.tsx:275, and verbatim in its .d.ts), so those
literals were checked against nothing whatever. MEASURED: with BOTH casts removed,
tsc --noEmit is green over a program --listFiles confirms contains ObjectView.tsx.
The casts were inert. Leaving one sitting exactly where the defect lived is what invites
the next reader to assume the shape was checked, so they are gone with the rungs, and a
comment block records the reasoning in place.

That prop-type gap is one seam out and in two other packages, so it is reported, not fixed
here: objectui#7946.

The pin

ObjectView.chartConfigForward-7891.test.tsx reads the schema ObjectView HANDS DOWN, one
arm per branch, plus a positive control per branch so an absence assertion cannot go green
on a mount that rendered nothing. The assertion is 'config' in schema, not
toBeUndefined() — the removed line emitted a PRESENT config: undefined key on every
chart view whether or not an author wrote one, so toBeUndefined() would have passed
against the defect itself.

Reverse verification, direction written before the run: re-injecting
config: chartConfig.config, into one literal was predicted to turn that branch's two
absence arms RED and leave the other four arms green.

• dataset branch re-injected: Tests 2 failed | 4 passed (6), the two failures being the
  dataset absence arms.
• legacy branch re-injected: Tests 2 failed | 4 passed (6), the two failures being the
  legacy absence arms.

Each leg confirmed the mutation on disk before reading (marker-count before/after, plus the
diff line), and each restored by STATE — git diff HEAD empty and the blob back to the HEAD
blob ef1b7e36675ace83a3d55520149cbc2119a8b85b — never by an exit code. The legacy leg's
FIRST attempt refused to run: its marker text is a substring of the dataset branch's
more-indented copy, the anchor assertion caught the ambiguity, and the script reported
"mutation did NOT land on disk" instead of silently mutating the wrong branch. Re-anchored
on surrounding lines and re-run.

Verification, all at e33c0c329

check-changeset-presence, verbatim:

2 source file(s) of 1 released package(s) changed, and this change declares 1
changeset(s): .changeset/olive-donkeys-invent.md.

Lint — a declared narrowing, with its evidence. eslint . --no-inline-config was run
whole rather than narrowed: 4332 files linted, 0 errors in either changed file under a
configuration stricter than CI's (it disables the eslint-disable-next-line comments CI
honours). The 93 errors it reports are the repo's pre-existing baseline under that flag,
across 77 other files. The CI-equivalent targeted run on the two changed files is 0 errors,
172 warnings, all no-explicit-any / react-refresh of the kind the lint workflow
deliberately does not cap. The config enables no type-aware linting (no project /
projectService in eslint.config.js), so this diff cannot move any verdict on a file it
did not touch.

Scope

packages/app-shell/src/views/ObjectView.tsx plus one pin test in the same package, and
the changeset. Nothing in packages/plugin-list/, packages/plugin-charts/,
packages/types/, or the objectstack repo — which was read only. In particular no config
rung was added to ListView, and no published schema was changed: declaring the key would
mint a second declaration of one that already exists, declared and documented, on the
standalone SDUI type: 'chart' component
(packages/types/src/zod/sdui/data-display.zod.ts:664).

Deleting a key the protocol already refuses by name changes no schema's accept/reject
behaviour, widens no public surface, and moves no gate's scan population — hence
Clause-②: no.

Related, none of them addressed here: objectui#7823 and its PR only made this reachable
(before them the block did not arrive on that route with a usable binding at all, so this
was not a regression they introduced); objectui#7946 is the prop-type gap above.

🤖 Generated with Claude Code

Generated by Claude Code